Fourth Generation (4G) wireless networks support large numbers of wireless subscribers running one or more applications wherein traffic is packetized and transported via IP networks according to multiple network elements utilizing different transport technologies and applied quality-of-service (QoS) policies. Contemporary wireless communication systems are designed to carry out several types of traffic types as generated by several applications. The applications may have very different (and even conflicting) QoS requirements. For instance, some applications, such as Machine-to-Machine or Instant Messages generate “thin” traffic, which places quite low demand on the user plane, but may be very bursty and have a significant impact on the control plane. On the other hand, some applications, such as video based applications, are less stressful on the control plane but may be very bandwith intensive on the user plane and subject to time critical constraints.
For example, Long Term Evolution (LTE) networks have the capability to deal with such applications having varied and/or conflicting QoS requirements. FIG. 1 depicts an exemplary wireless communication system including a LTE network. Specifically, FIG. 1 depicts an exemplary wireless communication system 100 that includes a plurality of User Equipments (UEs) or User Devices (UDs) 102, a Long Term Evolution (LTE) network 110, non-LTE access networks 120, IP networks 130, and a management system (MS) 140. The LTE network 110 supports communications between the UEs 102 and IP networks 130. The non-LTE access networks 120 interface with LTE network 110 for enabling UEs associated with non-LTE access networks 120 to utilize the LTE network 110 to access IP networks 130. The MS 140 is configured for supporting various management functions for LTE network 110.
The UEs 102 are wireless user devices capable of accessing a wireless network, such as LTE network 110. The UEs 102 are capable of supporting one or more bearer sessions to IP networks 130 via LTE network 110. The UEs 102 are capable of supporting control signaling in support of the bearer session(s). The UEs 102 each may have one or more identifiers associated therewith. For example, a UE 102 may have one or more of an International Mobile Subscriber Identity (IMSI), an International Mobile Equipment Identity (IMEI), and like identifiers or identities associated therewith. For example, each of the UEs 102 may be a phone, PDA, computer, or any other wireless user device. Multiple UDs are typically active at all times for each eNodeB (eNB).
The illustrated LTE network 110 is an exemplary LTE network. The configuration and operation of LTE networks will be understood by one skilled in the art. However, for purposes of completeness, a description of general features of LTE networks is provided herein within the context of exemplary wireless communication system 100.
The LTE network 110 includes two eNodeBs 1111 and 1112 (collectively, eNodeBs 111), two Serving Gateways (SGWs) 1121 and 1122 (collectively, SGWs 112), a Packet Data Network (PDN) Gateway (PGW) 113, two Mobility Management Entities (MMEs) 1141 and 1142 (collectively, MMEs 114), and a Policy and Charging Rules Function (PCRF) 115. The eNodeBs 111 provide a radio access interface for UEs 102. The SGWs 112, PGW 113, MMEs 114, and PCRF 115, as well as other components which have been omitted for purposes of clarity, cooperate to provide an Evolved Packet Core (EPC) network supporting end-to-end service delivery using IP.
The eNodeBs 111 support communications for UEs 102. As depicted in FIG. 1, each eNodeB 111 supports a respective plurality of UEs 102. The communication between the eNodeBs 111 and the UEs 102 is supported using LTE-Uu interfaces associated with each of the UEs 102. The eNodeBs 111 may support any functions suitable for being supported by an eNodeB, such as providing an LTE air interface for the UEs 102, performing radio resource management, facilitating communications between UEs 102 and SGWs 112, maintaining mappings between the LTE-Uu interfaces and S1-u interfaces supported between the eNodeBs 111 and the SGWs 112, and the like, as well as combinations thereof.
The SGWs 112 support communications for eNodeBs 111. As depicted in FIG. 1, SGW 1121 supports communications for eNodeB 1111 and SGW 1122 supports communications for eNodeB 1112. The communication between the SGWs 112 and the eNodeBs 111 is supported using respective S1-u interfaces for example. The S1-u interfaces support per-bearer user plane tunneling and inter-eNodeB path switching during handover. The S1-u interfaces may use any suitable protocol, e.g., the GPRS Tunneling Protocol-User Plane (GTP-U). The SGWs 112 may support any functions suitable for being supported by an SGW, such as routing and forwarding user data packets (e.g., facilitating communications between eNodeBs 111 and PGW 113, maintaining mappings between the S1-u interfaces and S5/S8 interfaces supported between the SGWs 112 and PGWs 113, and the like), functioning as a mobility anchor for UEs during inter-eNodeB handovers, functioning as a mobility anchor between LTE and other 3GPP technologies, and the like, as well as combinations thereof.
The PGW 113 supports communications for the SGWs 112. The communication between PGW 113 and SGWs 112 is supported using respective S5/S8 interfaces. The S5 interfaces provide functions such as user plane tunneling and tunnel management for communications between PGW 113 and SGWs 112, SGW relocation due to UE mobility, and the like. The S8 interfaces, which are Public Land Mobile Network (PLMN) variants of the S5 interfaces, provide inter-PLMN interfaces providing user and control plane connectivity between the SGW in the Visitor PLMN (VPLMN) and the PGW in the Home PLMN (HPLMN). The S5/S8 interfaces may utilize any suitable protocol (e.g., the GPRS Tunneling Protocol (GTP), Mobile Proxy IP (MPIP), and the like, as well as combinations thereof). The PGW 113 facilitates communications between LTE network 110 and IP networks 130 via an SGi interface. The PGW 113 may support any functions suitable for being supported by an PGW, such as providing packet filtering, providing policy enforcement, functioning as a mobility anchor between 3GPP and non-3GPP technologies, and the like, as well as combinations thereof.
The MMEs 114 provide mobility management functions in support of mobility of UEs 102. The MMEs 114 support the eNodeBs 111. The MME 1141 supports eNodeB 1111 and the MME 1142 supports eNodeB 1112. The communication between MMEs 114 and eNodeBs 111 is supported using respective S1-MME interfaces, which provide control plane protocols for communication between the MMEs 114 and the eNodeBs 111. The S1-MME interfaces may use any suitable protocol or combination of protocol. For example, the S1-MME interfaces may use the Radio Access Network Application Part (eRANAP) protocol while using the Stream Control Transmission Protocol (SCTP) for transport. The MMEs 114 support the SGW 112. The MME 1141 supports SGW 1121 and the MME 1142 supports SGW 1122. The communication between MMEs 114 and SGWs 112 is supported using respective S11 interfaces. The MMEs 1141 and 1142 communicate using an S10 interface. The MMEs 114 may support any functions suitable for being supported by a MME, such selecting SGWs for UEs at time of initial attachment by the UEs and at time of intra-LTE handovers, providing idle-mode UE tracking and paging procedures, bearer activation/deactivation processes, providing support for Non-Access Stratum (NAS) signaling (e.g., terminating NAS signaling, ciphering/integrity protection for NAS signaling, and the like), lawful interception of signaling, and the like, as well as combinations thereof. The MMEs 114 also may communicate with a Home Subscriber Server (HSS) using an S6a interface for authenticating users (the HSS and the associated S6a interface are omitted for purposes of clarity).
The PCRF 115 provides dynamic management capabilities by which the service provider may manage rules related to services provided via LTE network 110 and rules related to charging for services provided via LTE network 110. For example, rules related to services provided via LTE network 110 may include rules for bearer control (e.g., controlling acceptance, rejection, and termination of bearers, controlling QoS for bearers, and the like), service flow control (e.g., controlling acceptance, rejection, and termination of service flows, controlling QoS for service flows, and the like), and the like, as well as combinations thereof. For example, rules related to charging for services provided via LTE network 110 may include rules related to online charging (e.g., time-based charging, volume-based charging, event-based charging, and the like, which may depend on factors such as the type of service for which charging is being provided), offline charging (e.g., such as for checking subscriber balances before services are provided and other associated functions), and the like, as well as combinations thereof. The PCRF 115 communicates with PGW 113 using a S7 interface. The S7 interface supports transfer of rules from PCRF 115 to a Policy and Charging Enforcement Function (PCEF) supported by PGW 113, which provides enforcement of the policy and charging rules specified on PCRF 115.
As depicted in FIG. 1, elements of LTE network 110 communicate via interfaces between the elements. The interfaces described with respect to LTE network 110 also may be referred to as sessions. For example, the communication between eNodeBs and SGWs is provided via S1-u sessions, communication between SGWs and PGWs is provided via S5/S8 sessions, and so forth, as depicted in FIG. 1 and described herein. The sessions of LTE network 110 may be referred to more generally as S* sessions. It will be appreciated that each session S* that is depicted in FIG. 1 represents a communication path between the respective network elements connected by the session and, thus, that any suitable underlying communication capabilities may be used to support the session S* between the network elements. For example, a session S* may be supported using anything from direct hardwired connections to full network connectivity (e.g., where the session S* is transported via one or more networks utilizing nodes, links, protocols, and any other communications capabilities for supporting the communication path) and anything in between, or any other suitable communications capabilities.
For example, an S1-u session between an eNodeB 111 and an SGW 112 may be supported using an Internet Protocol (IP)/Multiprotocol Label Switching (MPLS) transport capability including mobile backhaul elements associated with the eNodeB 111 (e.g., using service aware routers (SARs), service access switches (SAS), and the like) and mobile backhaul elements associated with the SGW 112 (e.g., multi-service edge routers and/or other similar elements), as well as an IP/MPLS aggregation network facilitating communications between the mobile backhaul elements associated with the eNodeB 111 and the mobile backhaul elements associated with the SGW 112). Similarly, an S1-u session between an eNodeB 111 and an SGW 112 may be supported using an IP routing network using a routing protocol (e.g., Open Shortest Path First (OSPF), Intermediate System to Intermediate System (ISIS) and the like). The types of underlying communications capabilities which may be utilized to support each of the different types of sessions of LTE network 110 will be understood by one skilled in the art.
The LTE network 110 supports access to IP networks 130 from non-LTE networks 120. The non-LTE networks 120 with which the LTE network 110 may interface include 3GPP access networks 121. The 3GPP access networks 121 may include any 3GPP access networks suitable for interfacing with LTE network 110 (e.g., 2.5G networks, 3G networks, 3.5G networks, and the like). For example, the 3GPP access networks 121 may include Global System for Mobile (GSM) Enhanced Data Rates for GSM Evolution (EDGE) Radio Access Networks (GERANs), Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access Networks (UTRANs), or any other 3GPP access networks suitable for interfacing with LTE, and the like, as well as combinations thereof.
The LTE network 110 interfaces with 3GPP access networks 121 via a Serving General Packet Radio Service (GPRS) Support Node (SGSN) 122. The MME 1142 supports control plane functionality for mobility between LTE network 110 and 3GPP access networks 121 using communication with SGSN 122 via an S3 interface. For example, the S3 interface enables user and bearer information exchange for 3GPP network access mobility in idle and/or active state. The SGW 1122 supports user plane functionality for mobility between LTE network 110 and 3GPP access networks 121 using communication with SGSN 122 via an S4 interface. For example, the S4 interface provides the user plane with related control and mobility support between SGSN 122 and SGW 1122.
The non-LTE networks with which the LTE network may interface include non-3GPP access networks 125. The non-3GPP access networks 125 may include any non-3GPP access networks suitable for interfacing with LTE network 110. For example, the non-3GPP access networks may include 3GPP2 access networks (e.g., Code Division Multiple Access 2000 (CDMA 2000) networks and other 3GPP2 access networks), Wireless Local Area Networks (WLANs), and the like). The support for mobility between the LTE network 110 and the non-3GPP access networks 125 may be provided using any suitable interface(s), such as one or more of the S2a interface, the S2b interface, the S2c interface, and the like, as well as combinations thereof. The S2a interface provides control and mobility support to the user plane for trusted non-3GPP access to the LTE network. The S2a interface may provide access for trusted non-3GPP networks using any suitable protocol(s), such as MPIP, Client Mobile IPv4 Foreign Agent (FA) mode (e.g., for trusted non-3GPP access that does not support MPIP), and the like, as well as combinations thereof. The S2b interface provides control and mobility support to the user plane for non-trusted non-3GPP access to the LTE network. The S2b interface may be provided an interface between PGW 113 and an evolved Packet Data Gateway (ePDG) associated with the non-trusted non-3GPP access network. The S2b interface may use any suitable protocol, such as MPIP or any other suitable protocols. The S2c interface provides control and mobility support to the user plane for providing UEs access to PGW 113 via trusted and/or non-trusted 3GPP access using one or more protocols based on Client Mobile IP co-located mode.
The LTE network 110 includes an Evolved Packet System/Solution (EPS). In one embodiment, the EPS includes EPS nodes (e.g., eNodeBs 111, SGWs 112, PGW 113, MMEs 114, and PCRF 115) and EPS-related interconnectivity (e.g., the S* interfaces, the G* interfaces, and the like). The EPS-related interfaces may be referred to herein as EPS-related paths.
The IP networks 130 include one or more packet data networks via which UEs 102 may access content, services, and the like. For example, the IP networks 130 include an IP Core network and, optionally, one or more other IP networks (e.g., IP Multimedia Subsystem (IMS) networks and the like). The IP networks 130 support bearer and control functions in support of services provided to UEs 102 via LTE network 110. The IP Core network is capable of providing any functions which may be provided by such a core network. The IP Core network is a packet data network via which UEs 102 may access content, services, and the like. The IMS network is capable of providing any functions which may be provided by an IMS network.
The MS 140 provides management functions for managing the LTE network 110. Management functions of the MS may include discovery (discovery of information about the LTE networks such as configuration information, status/operating information, and connection information which is stored in a discovery database), correlation (correlation of discovered network elements to specific customer traffic flows supporting customer services which information is stored in a paths database), analysis of network information, auditing, trace for providing trace functionality, and fairness management for providing enforcement functionality.
The MS 140 may communicate with LTE network 110 in any suitable manner. In one embodiment, for example, MS 140 may communicate with LTE network 110 via a communication path 141 which does not traverse IP network networks 130. In one embodiment, for example, MS 140 may communicate with LTE network 110 via a communication path 142 which then passes via IP networks 130. The communication paths 141 and 142 may be implemented using any suitable communications capabilities.
The MS 140 is adapted to receive information from LTE network 110 (e.g., discovery information adapted for use in determining the topology of LTE network, results of test initiated by MS 140 to LTE network 110, and the like, as well as any other information which may be received by MS 140 from LTE network 110 in support of the management functions performed by MS 140). Similarly, for example, MS 140 is adapted to transmit information to LTE network 110 (e.g., discovery requests for discovering information adapted for use by MS 140 in determining the topology of LTE network, audits request for auditing portions of LTE network 110, and the like, as well as any other information which may be transmitted by MS 140 to LTE network 110 in support of the management functions performed by MS 140).
In dealing with applications, a conventional LTE network makes use of Buffer Status Report (BSR) messages. The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data available for transmission in the UpLink (UL) buffers of the UE. Radio Resource Control (RRC) controls BSR reporting by configuring two timers, a periodic BSR timer (e.g., “periodicBSR-Timer”) which indicates the periodic timing of a BSR message and a retransmit BSR timer (e.g., “retxBSR-Timer”) which indicates a retransmission wait period for retransmission of a BSR message upon transmission of the BSR message. Optionally, the RRC may also signal, for each logical channel, a logical channel group indicator (e.g., “logicalChannelGroup”) which allocates the logical channel to a Logical Channel Group (LCG). For the Buffer Status reporting procedure, the UE considers all radio bearers which are not suspended and may consider radio bearers which are suspended. In conjunction with such BSR messaging, the network attempts to provide a desired level of Quality of Service (QoS).
FIG. 2 represents an example flowchart illustrating the default LTE protocol 200 for sending Buffer Status Report (BSR) messages from a User Equipment (UE). At step 210, the UE is known to have an empty buffer. An empty buffer indicates that there is no data available for transmission in the UpLink (UL) buffers of the UE. At step 212, after packet arrival from the upper layer (i.e., application layer), the UE sends a regular BSR message which indicates the total buffer size to an eNB. The UE also starts the periodic BSR timer and starts the retransmit BSR timer. The UE then proceeds to wait for a grant message at step 214.
While waiting for the grant, if the retransmit BSR timer times out before receipt of the grant, the UE loops back to step 212 and again sends a regular BSR message, and restarts the periodic BSR timer and the retransmit BSR timer. Thus, the illustrated procedure will wait for a grant message for up to a period of time equivalent to the value of the retransmit BSR timer before resending a regular BSR message.
While waiting for the grant, if the grant is received before the retransmit BSR timer times out, the UE proceeds to step 216 where it is determined whether the buffer size is greater than the grant size. That is; it is determined whether the amount of data available for transmission in the UL buffers of the UE is larger than the grant size.
If the buffer size is not greater than the grant size, at step 218 the UE transmits data with the data size equal to the buffer size, and terminates the periodic BSR timer and the retransmit BSR timer. That is, the UE will transmit all data remaining in the UL buffers and end BSR timing. After these activities, the UE loops back to step 210 at which point the buffer is once again known to be empty.
If the buffer size is greater than the grant size, the UE determines whether the periodic BSR timer has expired at step 220. The value of the periodic BSR timer indicates a period of time to wait between transmissions of BSR messages. If the periodic BSR timer has not expired, the UE transmits a data message with data size equivalent to the grant size at step 222 and then returns to step 214 to await another grant so as to be permitted to transmit additional portion(s) of the data remaining in the UL buffers at the UE. If the periodic BSR timer has expired, at step 224, the UE prepares a periodic BSR message to report the buffer size as the buffer size minus the difference of the grant size minus the BSR message size, transmits a data message with data equivalent to the grant size minus the BSR message size, and restarts the periodic BSR timer and the retransmit BSR timer. Thus, after receiving a grant that is not larger than the buffer size (i.e., amount of data available for transmission in the UL buffer(s) of the UE) and expiration of the periodic BSR timer, the illustrated procedure sends a periodic BSR message and a portion of the data in the UL buffer(s) of the UE. The UE then returns to step 214 to await a grant to be able to transmit additional portion(s) of the data remaining in the UL buffers at the UE.
Additional description for the BSR is found in the 3GPP document TS 36.321 and the potential values for periodic BST timer (e.g., “periodicBSR-Timer”) and retransmit BSR timer (e.g., “retxBSR-Timer”) are provided in the RRC document, namely 3GPP TS 36.331 both of which are known to those skilled in the art of the invention and herein incorporated by reference. MAC-MainConfig topic of section 6.3.2 in 3GPP TS 36.331 lists those values for both timers. Some default values are suggested in section 9.2.2 of the same document. The periodic BSR timer “periodicBSR-Timer” (default=infinity) is optional and the values are sf5, sf10, sf16, sf20, sf32, sf40, sf64, sf80, sf128, sf160, sf320, sf640, sf1280, sf2560, infinity and spare1 (“sf5” means subframe 5 and it is equivalent to 5 msec; “sf10” means subframe 10 and it is equivalent to 10 msec, etc.). The retransmit BSR timer “retxBSR-Timer” (default=sf2560) values are sf320, sf640, sf1280, sf2560, sf5120, sf10240, spare2 and spare1.
FIG. 3 is an example communication flow illustrating UE-eNB packet transmissions according to the protocol for sending BSR messages detailed in FIG. 2. In the illustrated example of FIG. 3, the periodic BSR timer is set to five (5) subframes and the retransmit BSR timer is set two-thousand five-hundred sixty (2560) subframes. Time, denoted by times instances numbered T99, T100, . . . T113 runs from the top to bottom of FIG. 3. While both periodic BSR timer and the retransmit BSR timer are utilized, activity associated with the expiration of the retransmit BSR timer is not in action/invoked in the illustrated example of FIG. 3.
At time T99, fifteen hundred (1500) bytes are placed in the UL buffer/s of the UE. At time T100, a regular BSR message is transmitted from the UE to the eNB. The BSR message is characterized as regular since it is the initial BSR message. The BSR message indicates that there are fifteen hundred (1500) bytes are in the buffer of the UE (i.e., fifteen hundred (1500) bytes available for transmission in the UL buffers of the UE). At time T101, an additional three hundred (300) bytes are placed in the UL buffers of the UE. At time T102, the eNB transmits a first grant message to the UE; the UE receives from the eNB the first grant for five hundred (500) bytes. The buffer size being greater than the grant size and the periodic BSR timer not yet having expired (FIG. 2: 216, 220), at time T103, the UE transmits a first data message of five hundred (500) bytes (FIG. 2: 222). At time T105, while waiting for the next grant (FIG. 2: 214), the periodic BSR timer has expired and the UE is ready to prepare a periodic BSR message (P_BSR). The periodic timer expires on T105 since the timer value is 5 subframes/5 ms.
At time T106, the UE receives from the eNB a second grant for five hundred (500) bytes. Buffer size is now thirteen hundred bytes (1500 at start+300 added−500 transmitted=1300). The buffer size being greater than the grant size and the periodic BSR timer having expired (FIG. 2: 216, 220), at time T107, the UE prepares and transmits a periodic BSR message data message and a second data message (FIG. 2: 224). The periodic BSR message transmitted reports the buffer size as eight hundred ten (810) bytes, which is the buffer size (1300 bytes) minus the difference of the grant size (500 bytes) minus the BSR message size (e.g., 10 bytes). The transmitted data message has a data size equal to four hundred ninety (490) bytes, which is a size equivalent to the grant size (500 bytes) minus the BSR message size (e.g., 10 bytes).
At time T108, the eNB transmits a third grant to the UE; the UE receives from the eNB the third grant for eight hundred ten (810) bytes. The buffer size not being greater than the grant size (FIG. 2: 216), at time T110, the UE transmits a third data message with a data size equivalent to the grant of eight hundred ten (810) (FIG. 2: 218). The UL buffers of the UE are now empty and the illustrative example ends.